Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

GFramework.Game/Config/GameConfigBootstrap.cs (1)

153-177: ⚠️ Potential issue | 🟠 Major

InitializeAsync() still leaks loaded tables through Registry on hot-reload startup failure.

LoadAsync(Registry, ...) commits into the shared registry before EnableHotReload(...) runs. If watcher creation then throws, _loader and _hotReload stay unpublished, but callers can already observe the new tables through bootstrap.Registry; the Architecture sample in this PR even registers that registry before InitializeAsync(). That means this path does not actually preserve the previous stable state, and a retry may now start from an already-mutated registry.

Based on learnings "Preserve deterministic behavior in registries, lifecycle orchestration, and generated outputs in C# code" and "When adding caching, pooling, or shared mutable state in C#, document thread-safety assumptions and failure modes".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@GFramework.Game/Config/GameConfigBootstrap.cs` around lines 153 - 177,
InitializeAsync currently calls YamlConfigLoader.LoadAsync(Registry, ...) which
mutates the shared Registry before EnableHotReload(...) completes, allowing a
failing hot-reload startup to leave partially-applied tables visible; fix by
loading into a temporary/staging Registry instance (or have
YamlConfigLoader.LoadAsync accept a target Registry parameter you supply that is
not the shared Registry), call loader.LoadAsync(stagingRegistry, ...), then call
loader.EnableHotReload(stagingRegistry, _options.HotReloadOptions) and only
inside the lock(_stateGate) swap _loader/_hotReload and replace the real
Registry with the stagingRegistry if both load and watcher creation succeed;
ensure no changes are applied to the shared Registry if EnableHotReload throws
and preserve the previous Registry and _loader/_hotReload state, and keep
setting _isInitializing = false in the finally block as before.

.github/workflows/ci.yml (1)

137-139: Use frozen lockfile for deterministic CI installs.

Line 139 should use --frozen-lockfile to prevent dependency drift across CI runs. A bun.lock file exists in the project, and Bun's frozen lockfile mode ensures reproducible installs by requiring exact version matches.

Proposed patch

-      - name: Install config tool dependencies
-        working-directory: tools/gframework-config-tool
-        run: bun install
+      - name: Install config tool dependencies
+        working-directory: tools/gframework-config-tool
+        run: bun install --frozen-lockfile

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml around lines 137 - 139, Update the CI step named
"Install config tool dependencies" to use Bun's frozen lockfile mode: replace
the current run command that invokes "bun install" (in the step labeled Install
config tool dependencies under working-directory tools/gframework-config-tool)
with "bun install --frozen-lockfile" so the existing bun.lock is enforced and
installs are deterministic across CI runs.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

GFramework.Game.Tests/Config/GameConfigBootstrapTests.cs (1)

114-128: ⚠️ Potential issue | 🟠 Major

Add constructor coverage for invalid RootPath contract branch.

This currently verifies the missing ConfigureLoader branch, but it skips the sibling constructor validation for RootPath (null/empty/whitespace). That leaves one public API guard branch unpinned and easier to regress.

🧪 Suggested test addition

 [Test]
 public void Constructor_Should_Throw_When_ConfigureLoader_Is_Missing()
 {
     var exception = Assert.Throws<ArgumentException>(() =>
         _ = new GameConfigBootstrap(
             new GameConfigBootstrapOptions
             {
                 RootPath = _rootPath
             }));

     Assert.That(exception!.ParamName, Is.EqualTo("options"));
 }
+
+[Test]
+public void Constructor_Should_Throw_When_RootPath_Is_Whitespace()
+{
+    var exception = Assert.Throws<ArgumentException>(() =>
+        _ = new GameConfigBootstrap(
+            new GameConfigBootstrapOptions
+            {
+                RootPath = "   ",
+                ConfigureLoader = static _ => { }
+            }));
+
+    Assert.That(exception!.ParamName, Is.EqualTo("options"));
+}

Based on learnings "When a public API defines multiple contract branches, tests MUST cover the meaningful variants, including null, empty, default, and filtered inputs when those branches change behavior".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@GFramework.Game.Tests/Config/GameConfigBootstrapTests.cs` around lines 114 -
128, Add a new unit test in GameConfigBootstrapTests that asserts the public
constructor GameConfigBootstrap throws (ArgumentException or
ArgumentNullException as the API defines) when
GameConfigBootstrapOptions.RootPath is null, empty, or whitespace; locate the
constructor under test (new GameConfigBootstrap(GameConfigBootstrapOptions)) and
add parameterized cases (null, "", "   ") verifying the thrown exception and
ParamName equals "options" or "RootPath" per the constructor's contract so the
RootPath guard branch is covered alongside the existing ConfigureLoader test.

docs/zh-CN/game/config-system.md (1)

669-693: 热重载主示例建议与前文统一为 GameConfigBootstrap.StartHotReload(...)

前文（Line 424 起）已把 GameConfigBootstrap.StartHotReload(...) 定义为推荐路径，但这里仍用 loader.EnableHotReload(...) 作为主示例，读者容易把“兼容入口”误解为“首选入口”。建议把此段主示例改为 bootstrap 版本，并把 EnableHotReload 下沉为“底层高级用法”小节。

📌 文档示例调整建议

-## 开发期热重载
-
-如果你希望在开发期修改配置文件后自动刷新运行时表，可以在初次加载完成后启用热重载：
+## 开发期热重载
+
+如果你希望在开发期修改配置文件后自动刷新运行时表，推荐沿用统一入口，在初次加载完成后通过 `GameConfigBootstrap.StartHotReload(...)` 启用：

 ```csharp
-using GFramework.Game.Abstractions.Config;
-using GFramework.Game.Config;
-using GFramework.Game.Config.Generated;
-
-var registry = new ConfigRegistry();
-var loader = new YamlConfigLoader("config-root")
-    .RegisterAllGeneratedConfigTables();
-
-await loader.LoadAsync(registry);
-
-var hotReload = loader.EnableHotReload(
-    registry,
-    onTableReloaded: tableName => Console.WriteLine($"Reloaded: {tableName}"),
-    onTableReloadFailed: (tableName, exception) =>
-    {
-        var diagnostic = (exception as ConfigLoadException)?.Diagnostic;
-        Console.WriteLine($"Reload failed: {tableName}, {exception.Message}");
-        Console.WriteLine($"Failure kind: {diagnostic?.FailureKind}");
-    });
+await bootstrap.InitializeAsync();
+bootstrap.StartHotReload(
+    new YamlConfigHotReloadOptions
+    {
+        OnTableReloaded = tableName => Console.WriteLine($"Reloaded: {tableName}"),
+        OnTableReloadFailed = (tableName, exception) =>
+        {
+            var diagnostic = (exception as ConfigLoadException)?.Diagnostic;
+            Console.WriteLine($"Reload failed: {tableName}");
+            Console.WriteLine($"Failure kind: {diagnostic?.FailureKind}");
+        }
+    });

+如果你需要直接控制底层加载器，再使用 YamlConfigLoader.EnableHotReload(...)。

</details>

As per coding guidelines "Keep code samples, package names, and command examples in documentation aligned with the current repository state" and "Update the relevant `README.md` or `docs/` page when behavior, setup steps, architecture guidance, or user-facing examples change".

<details>
<summary>🤖 Prompt for AI Agents</summary>

Verify each finding against the current code and only fix it if needed.

In @docs/zh-CN/game/config-system.md around lines 669 - 693, The current
hot-reload example uses YamlConfigLoader.EnableHotReload which conflicts with
the earlier recommended GameConfigBootstrap.StartHotReload; update the example
to call bootstrap.InitializeAsync() followed by
GameConfigBootstrap.StartHotReload(...) using a YamlConfigHotReloadOptions
object (set OnTableReloaded and OnTableReloadFailed and map the diagnostic
extraction from ConfigLoadException as shown), and move the
YamlConfigLoader.EnableHotReload snippet into a separate "advanced / low-level
usage" subsection so readers see StartHotReload
(GameConfigBootstrap.StartHotReload) as the primary example while preserving
EnableHotReload (YamlConfigLoader.EnableHotReload) as an alternative.

</details>

</blockquote></details>

</blockquote></details>

<details>
<summary>🤖 Prompt for all review comments with AI agents</summary>

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @docs/zh-CN/game/config-system.md:

• Around line 669-693: The current hot-reload example uses
  YamlConfigLoader.EnableHotReload which conflicts with the earlier recommended
  GameConfigBootstrap.StartHotReload; update the example to call
  bootstrap.InitializeAsync() followed by GameConfigBootstrap.StartHotReload(...)
  using a YamlConfigHotReloadOptions object (set OnTableReloaded and
  OnTableReloadFailed and map the diagnostic extraction from ConfigLoadException
  as shown), and move the YamlConfigLoader.EnableHotReload snippet into a separate
  "advanced / low-level usage" subsection so readers see StartHotReload
  (GameConfigBootstrap.StartHotReload) as the primary example while preserving
  EnableHotReload (YamlConfigLoader.EnableHotReload) as an alternative.

</details>

---

<details>
<summary>ℹ️ Review info</summary>

<details>
<summary>⚙️ Run configuration</summary>

**Configuration used**: Path: .coderabbit.yaml

**Review profile**: CHILL

**Plan**: Pro

**Run ID**: `154ad9ba-7c9b-4478-b8b9-2e06ebf79f7c`

</details>

<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between cd32a006c69eab0d38a80b20c419535117ea5d7b and d99af1cfac58e27edb9bc1d3b9fac836e603f582.

</details>

<details>
<summary>📒 Files selected for processing (1)</summary>

* `docs/zh-CN/game/config-system.md`

</details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->